System and method for failover handling at geo-redundant gateways

ABSTRACT

A method, system and apparatus for reversion of UE sessions from a backup SGW or protect node to an operationally restored primary SGW or working node.

CROSS REFERENCE TO RELATED APPLICATIONS

This patent application claims priority to U.S. Provisional PatentApplication Ser. No. 61/454,328, entitled GEO-REDUNDANCE IN A SERVINGGATEWAY, filed Mar. 18, 2011, which is herein incorporated by referencein its entirety.

This patent application is related to simultaneously filed U.S. patentapplication Ser. No. 13/423,247, filed on Mar. 18, 2012, entitled SYSTEMAND METHOD FOR SESSION RESILIANCY AT GEO-REDUNDANT GATEWAYS, and Ser.No. 13/423,249, filed on Mar. 18, 2012, entitled SYSTEM AND METHOD FORSESSION RESTORATION AT GEO-REDUNDANT GATEWAYS, both of which are hereinincorporated by reference in their entireties.

FIELD OF THE INVENTION

The invention relates generally to managing network resources and, morespecifically but not exclusively, adapting operations associated with asystem router such as a Serving Gateway (SGW).

BACKGROUND

A wireless network, illustratively a Long Term Evolution (LTE) network,may comprise groups of mobile telephones or other user equipment (UE)communicating with one or more eNodeBs, which communicate with one ormore Serving Gateways (SGWs), which communicate with a Packet DataNetwork (PDN) Gateway (PGW), which communicates with fixed networks suchas IP Multimedia Subsystem (IMS) access networks or core networks.Additionally, the LTE network includes various network elements such asMobility Management Entities (MMEs), a Policy and Charging RulesFunction (PCRF), a network management system (NMS) and so on.

In a failure scenario where a Serving Gateway (SGW) loses connectivitywith other nodes in the network (e.g., due to network disconnection,power failure, or even a triggered behavior based on partial failures),a backup SGW must take over operations. This should be accomplished inan intelligent manner to avoid unreasonable spiking in resourceutilization while continuing to meet reasonable user/subscriberexpectations.

When the primary SGW fails, all of the packets destined for the failedSGW are dropped. In addition, the MME will lose path management statesassociated with the failed SGW and will need clean up all its activesessions. This will cause the active UEs to re-connect to the networkthrough the backup SGW or an alternate SGW. Similarly, the PGW will loseits path management state to the SGW, and will clean up session statetowards the IMS subsystem (all UEs are active on the PGW and into thenetwork). With the active UEs re-attaching, their state will be restoredto the PGW and the IMS subsystem.

However, since the majority of UEs are idle at any given moment, at thetime of the primary SGW failure the MME will not reach out to the idleUEs to clean up their sessions. This is because the first step tocleaning up the idle UE sessions is to page each of the idle UEs, whichis prohibitively expensive. If an idle UE is not cleaned up, there is noway for a network-initiated call to reach it because no network entityknows where in the network it is currently located. Moreover, the IMSsub-system cannot find the UE and no entity is actively encouraging theUE to re-identify itself. The consequence is significant as the UE willnot be reachable for up to an hour or two, depending on various timers.This is unacceptable for users.

BRIEF SUMMARY

Various deficiencies of the prior art are addressed by the presentinvention of a method, system and apparatus for reversion of UE sessionsfrom a backup SGW or protect node to an operationally restored primarySGW or working node.

In one embodiment, a method, system and apparatus contemplates, inresponse to a determination that a primary SGW has returned tooperation, synchronizing user equipment (UE) session state informationbetween backup and primary SGWs for at least those UEs previouslysupported by the primary SGW; and in response to a revertive actiontrigger, creating a handover channel between the backup and primary SGWsto enable a transition of UE support from the backup SGW to the primarySGW.

BRIEF DESCRIPTION OF THE DRAWINGS

The teachings of the present invention can be readily understood byconsidering the following detailed description in conjunction with theaccompanying drawings, in which:

FIG. 1 depicts an exemplary communication system benefiting from anembodiment;

FIG. 2 depicts an exemplary Serving Gateway (SGW) router architecturesuitable for use in communication system of FIG. 1;

FIG. 3 depicts a flow diagram of a session state backup method accordingto an embodiment;

FIG. 4 depicts a flow diagram of a session state restoration methodaccording to an embodiment;

FIG. 5 depicts a flow diagram of a revertive action method according toone embodiment; and

FIG. 6 depicts a high-level block diagram of a general purpose computersuitable for use in performing the functions described herein withrespect to the various embodiments.

To facilitate understanding, identical reference numerals have beenused, where possible, to designate identical elements that are common tothe figures.

DETAILED DESCRIPTION OF THE INVENTION

The invention will be primarily described within the context of a LongTerm Evolution (LTE) network in which Service Gateway (SGW) redundancysuch that both active and idle subscribers are transitioned from afailed SGW to a backup SGW.

Although primarily depicted and described herein within the context ofproviding management and backup functions within a 4G LTE wirelessnetwork, it will be appreciated that the management and backup functionsdepicted and described herein may be utilized within other types ofwireless networks (e.g., 2G networks, 3G networks, WiMAX, etc.),wireline networks or combinations of wireless and wireline networks.Thus, the various network elements, links and other functional entitiesdescribed herein with respect to an LTE network may be broadly construedto identify corresponding network elements, links and other functionalentities associated with various other types of wireless and wirelinenetworks.

Part of the invention rests in the recognition of the inventors that thedramatically increasing size of wireless networks in particular leads tospecific network management problems that are not properly addressed byexisting solutions. In particular, it was recognized by the inventorsexisting solutions scaled poorly and failed to address the reality thatsubscriber equipment may be in various steady states (such as Idle orActive states), or in various transitional states (such as progressingbetween call flows, moving between an Idle state and an Active state,engaged in a handover from one eNodeB to another, creating a dedicatedbearer, destroying a PDN session and so on). Furthermore, subscribertraffic may be flowing to or from the subscriber in any one of the studyor transitional states.

FIG. 1 depicts an exemplary wireless communication system includingmanagement and backup/protection functions according to an embodiment.Specifically, FIG. 1 depicts an exemplary wireless communication system100 that includes a plurality of User Equipment (UEs) 102, a Long TermEvolution (LTE) network 110, IP networks 130, and a network managementsystem (NMS) 140. The LTE network 110 supports communications betweenthe UEs 102 and IP networks 130. The MS 140 is configured for supportingvarious management functions for LTE network 110. The configuration andoperation of LTE networks will be understood by one skilled in the art.

The exemplary UEs 102 are wireless user devices capable of accessing awireless network, such as LTE network 110. The UEs 102 are capable ofsupporting control signaling in support of the bearer session(s). TheUEs 102 may be mobile phones, personal digital assistants (PDAs),computers, tablets devices or any other wireless user device.

The exemplary LTE network 110 includes, illustratively, two eNodeBs 111₁ and 111 ₂ (collectively, eNodeBs 111), two Serving Gateways (SGWs) 112₁ and 112 ₂ (collectively, SGWs 112), a Packet Data Network (PDN)Gateway (PGW) 113, a Mobility Management Entity (MME) 114, and a Policyand Charging Rules Function (PCRF) 115. The eNodeBs 111 provide a radioaccess interface for UEs 102. The SGWs 112, PGW 113, MME 114, and PCRF115, as well as other components which have been omitted for purposes ofclarity, cooperate to provide an Evolved Packet Core (EPC) networksupporting end-to-end service delivery using IP.

The eNodeBs 111 support communications for UEs 102. As depicted in FIG.1, each eNodeB 111 supports a respective plurality of UEs 102. Thecommunication between the eNodeBs 111 and the UEs 102 is supported usingLTE-Uu interfaces associated with each of the UEs 102.

The SGWs 112 support communications for eNodeBs 111 using,illustratively, respective S1-u interfaces between the SGWs 112 and theeNodeBs 111. The S1-u interfaces support per-bearer user plane tunnelingand inter-eNodeB path switching during handover.

As depicted in FIG. 1, SGW 112 ₁ supports communications for eNodeB 111₁ and SGW 112 ₂ supports communications for eNodeB 111 ₂. In variousprotection/backup embodiments, SGW 112 ₁ is also capable of supportingcommunications for eNodeB 111 ₂ and SGW 112 ₂ is also capable ofsupporting communications for eNodeB 111 ₁.

The PGW 113 supports communications for the SGWs 112 using,illustratively, respective S5/S8 interfaces between PGW 113 and SGWs112. The S5 interfaces provide functions such as user plane tunnelingand tunnel management for communications between PGW 113 and SGWs 112,SGW relocation due to UE mobility, and the like. The S8 interfaces,which may be Public Land Mobile Network (PLMN) variants of the S5interfaces, provide inter-PLMN interfaces providing user and controlplane connectivity between the SGW in the Visitor PLMN (VPLMN) and thePGW in the Home PLMN (HPLMN). The PGW 113 facilitates communicationsbetween LTE network 110 and IP networks 130 via an SGi interface.

The MME 114 provide mobility management functions in support of mobilityof UEs 102. The MME 114 supports the eNodeBs 111 using, illustratively,respective S1-MME interfaces which provide control plane protocols forcommunication between the MME 114 and the eNodeBs 111.

The PCRF 115 provides dynamic management capabilities by which theservice provider may manage rules related to services provided via LTEnetwork 110 and rules related to charging for services provided via LTEnetwork 110.

As depicted and described herein with respect to FIG. 1, elements of LTEnetwork 110 communicate via interfaces between the elements. Theinterfaces described with respect to LTE network 110 also may bereferred to as sessions. The LTE network 110 includes an Evolved PacketSystem/Solution (EPS). In one embodiment, the EPS includes EPS nodes(e.g., eNodeBs 111, SGWs 112, PGW 113, MME 114, and PCRF 115) andEPS-related interconnectivity (e.g., the S* interfaces, the G*interfaces, and the like). The EPS-related interfaces may be referred toherein as EPS-related paths.

The IP networks 130 include one or more packet data networks via whichUEs 102 may access content, services, and the like.

The MS 140 provides management functions for managing the LTE network110. The MS 140 may communicate with LTE network 110 in any suitablemanner. In one embodiment, for example, MS 140 may communicate with LTEnetwork 110 via a communication path 141 which does not traverse IPnetworks 130. In one embodiment, for example, MS 140 may communicatewith LTE network 110 via a communication path 142 which is supported byIP networks 130. The communication paths 141 and 142 may be implementedusing any suitable communications capabilities. The MS 140 may beimplemented as a general purpose computing device or specific purposecomputing device, such as described below with respect to FIG. 10.

FIG. 2 depicts an exemplary Serving Gateway (SGW) router architecturesuitable for use in communication system of FIG. 1. Specifically, FIG. 1depicts a router 200 operating as a SGW such as SGW 112 depicted abovewith respect to FIG. 1. The router 200 communicates with various networkelements (not shown) via a network 110, such as the network 110 depictedabove with respect to FIG. 1. It will be appreciated by those skilled inthe art that the specific topology depicted herein with respect to theSGW 200 may be modified while maintaining the basic SGW functionality.

The SGW 200 is depicted as including a plurality of input output (I/O)cards 210-1, 210-2 and so on up to 210-N (collectively I/O cards 210), aswitch fabric 220 and a control module 230. The control module 230controls the operation of the I/O cards 210 and switch fabric 220 byrespective control signals CONT. The control module 230 also performsvarious SGW functions as described herein.

Each of the I/O cards 210 includes a plurality of ingress ports, egressports, controllers and so on (not shown) which operate to convey packetsbetween the network 110 and the switch fabric 220. Packets received at aparticular ingress port of an I/O card 210 may be conveyed to the switchfabric 220 or back to the network 110 via an egress port of the same I/Ocard 210 or a different I/O card 210. Routing of packets via the I/Ocards 210 is accomplished in a standard manner according to routing dataprovided by the control module 230

The switch fabric 220 may comprise any standard switch fabric such aselectrical, optical, electro-optical, MEMS and the like.

The control module 230 receives configuration data, routing data, policyinformation and other information pertaining to various SGW operationaland management functions from a network manager (not shown), such as thenetwork management system (NMS) 140 discussed above with respect toFIG. 1. The control module 230 also provides configuration data, statusdata, alarm data, performance data and other information pertaining tooperational and management functions to the network manager.

The control module 230 comprises an I/O module 231, a processor 232 andmemory 233. The memory 233 is depicted as including software modules,instantiated objects and the like to provide a SGW manager 233SGWM, abackup and recovery manager 23BARM, session data 233SD, router data233RD and other functions/data 2330. The control module 230 may beimplemented as a general purpose computing device or specific purposecomputing device, such as described below with respect to FIG. 6.

The SGW manager 233SGWM operates to manage the various Serving Gateway(SGW) functions as known to those skilled in the art and furtherdescribed herein.

The backup and recovery manager 23BARM operates to manage the backup andrecovery functions described herein with respect to the variousembodiments. For example, such backup and recovery functions may bedifferent depending upon whether the SGW is operating as a primary oractive SGW, a secondary or backup SGW, or both. Generally speaking, thevarious embodiments contemplate the transport and storage at a backupSGW of some or all of the session related data associated with userequipment or mobile devices for subscribers supported by the active SGW,such that rapid recovery of both active and idle sessions may beprovided to such subscribers.

The session data 233SD comprises session data associated with userequipment or mobile devices for subscribers. If the SGW is operating asa primary or active SGW, then the session data 233SD may compriseinformation supporting the user equipment or mobile devices forsubscribers forth by the primary or active SGW. If the SGW is operatingas a secondary or backup SGW, then the session data 233SD may comprise aportion of the session data associated with one or more primary oractive SGWs supported by the backup SGW.

The routing data 233RD comprises routing information associated with thepacket or traffic flows to be processed by the SGW, such as forprocessing packet or traffic flows received at ingress ports that are tobe routed toward appropriate egress ports within the context of basicrouting functions of the SGW. The routing data 233RD may include routingtables, protection or fault recovery information and so on.

The other functions/data 2330 comprises programs, functions, datastructures and the like operative to perform the various functionsdescribed herein with respect to standard SGW operations as well as SGWoperations according to various embodiments which are not explicitlyattributed to other management or data entities.

Backup SGW Selection and Geo-Redundant Pairing

The MME may be alerted to the failure of an SGW by nodes or networkelements adjacent to the failed SGW. These adjacent nodes or networkelements may independently take corrective action to re-establishconnectivity through a previously assigned backup SGW, through a backupSGW identified by the MME, or through some other routing means.

In various embodiments, a specific backup SGW is assigned to one or moreprimary or active SGWs within the network by, illustratively, thenetwork management system (NMS). A selected backup SGW may be the SGWmost geographically proximate to a primary or active SGW. Moreover, someprimary or active SGWs may operate as backup SGWs to other primary oractive SGWs.

In various embodiments, a specific backup SGW is selected after afailure of a primary or active SGW. In these embodiments the backup SGWmay be selected based on various criteria, including some or all ofgeographic proximity to the failed SGW, DNS response criteria, pathmanagement verification criteria, session loading, and various othercriteria. In various embodiments, the selection of a backup SGW is madeby the MME from, for example, a pool of SGWs available to the particularMME which is drawn upon to provide a backup SGW in the event of one ofthe pooled SGWs fails.

In one embodiment, SGWs 112 are geographically proximate each other suchthat may be used to form a geo-redundant pair of SGWs. Generallyspeaking, traffic and data flows from UEs 102 of a particular eNodeB 111are primarily routed to the PGW 113 via a particular SGW, the particularSGW functioning as a primary or working SGW with respect to the voiceand data traffic from the eNodeB. That is, one of the SGWs is configuredas a working or primary node while the other is configured as aprotection or backup node. In a normal state of operations (i.e., nofailure), the working node operates to process calls flows and dataflows from, illustratively, a plurality of eNodeBs while the protectionnode operates to back up the working node in case of a failure of theworking node.

In one embodiment, first SGW 112 ₁ operates as a primary or working SGWwith respect to voice and data traffic from the first eNodeB 111 ₁,while the second SGW 112 ₂ operates as a secondary or backup SGW withrespect to voice and data traffic from the first eNodeB 111 ₁.

In one embodiment, second SGW 112 ₂ operates as a primary or working SGWwith respect to voice and data traffic from the second eNodeB 111 ₂,while the first SGW 112 ₁ operates as a secondary or backup SGW withrespect to voice and data traffic from the second eNodeB 111 ₂.

In one embodiment, the first and second SGWs 112 operate as primary orworking SGWs with respect to voice and data traffic from their own one(or more) respective eNodeBs, and secondary or backup SGWs with respectto voice and data traffic from the one (or more) eNodeBs associated withthe other SGW.

Various embodiments discussed herein are directed toward rapidlyrestoring sessions, voice and data traffic, and various other managementinformation or contexts associated with such UEs 102 in response to afailure of the primary working SGW. In particular, to provide rapid andefficient protection/backup functions between the SGWs, variousembodiments contemplate several levels of redundant storage of sessionstate information associated with user equipment to enable rapidtransition to the backup SGW without significant impact to subscriberexperience. In particular, session state information redundancy enablesboth the MME 114 and PGW 113 to maintain state information for idlesubscriber UE such that active sessions may be rapidly reestablished andthe subscriber experience and enhanced.

Failover Handling

Within the context of “transferring” support for UEs 102 and/or eNodeBs111 from a failed or failing SGW 112 to a backup SGW 112 (and thenmigrated in whole or in part back to the primary SGW when it becomesoperational again), full survivability of user sessions may not alwaysbe achievable. However, the various embodiments discussed herein areadapted to promote fast restoration of services utilizing on-demandrestoration of services while maintaining a low synchronization overheadbetween active and backup SGWs.

On-demand restoration of services is where a backup SGW only processessessions that are requesting activity. On an SGW in active use, theremay be a large number of idle sessions that do not require immediaterestoration. Over a period of time, these sessions become active, and atthat time, it becomes necessary to reconnect those sessions. With thisjust-in-time restoration approach, the network is not overburdened withsignaling overheads for sessions that are not active.

Low synchronization overhead is where data synchronization operations,session state updates and the like between a primary SGW and its backupSGW are kept to a minimum. Typically, there is significant trafficbetween an active SGW and a MME directed toward various functions suchas keeping track of sessions that are becoming active, going idle, orhanding over from one eNodeB to another. These activities happen sofrequently that it is a significant burden to communicate all thesechanges between the active and backup SGWs. Generally speaking, thevarious embodiments utilize only the knowledge of which sessions existedon the active SGW at the time of the failure.

The various methodologies and techniques described herein provide amechanism by which both control and data planes of user sessions on aprimary SGW may be restored via a backup SGW (and then migrated in wholeor in part back to the primary SGW when it becomes operational again) inresponse to a failure of the primary SGW. Various embodiments of thesession restoration mechanism described herein address three components;namely, (1) IP address survivability, (2) path management continuity,and (3) session restoration.

IP address survivability is the process of ensuring that networkelements connected to the backup SGW continue to be able to access theIP address(es) of the failed SGW throughout the transfer process to thebackup SGW.

In some embodiments, IP address survivability is implemented using avirtual IP address, such as through the use of VRRP (layer 2 approach)or anycast IP address (layer 3 approach).

In some embodiments, IP address survivability is implemented by havingthe active and backup SGW advertise the same IP address, wherein theactive SGW advertising the IP address with a highly preferred metricwhile the backup SGW advertises the IP address with a non-preferred or“poisoned” metric. In these embodiments, any network elements choosingbetween the advertise IP addresses will always choose that of the activeSGW since this address is highly preferred. When the active SGW failsand the only valid IP address is that advertised by the backup SGW, thennetwork elements will choose the backup SGW all data plane and controlplane traffic.

Path management continuity is the process of ensuring that networkelements with path management to the failed SGW maintain continuitythrough the transfer process to the backup SGW. In some embodiments, theactive SGW engages in a periodic path management relationship withvarious other network elements (e.g., MME, eNodeB, PGW). Each pathmanagement instance is identified by a Restart Counter that is sent inan Echo Request. If this number changes, it signifies that the networkelement has been restarted (because of a reboot or an administrativeaction that brought the network element down and back up).

When the backup SGW takes over, it receives path management EchoRequests and responsively transmits Echo Replies. In addition, thebackup SGW sends Echo Requests and field Echo Replies. For every peer,the backup SGW will know the received Restart Counter at the active SGW.In this manner, if a Restart Counter from a peer changes then the backupSGW may responsively clean up sessions associated with that peer. Invarious embodiments, when the backup SGW sends Echo Requests it willalso send the Restart Counter that the active SGW used to send. In thismanner, peers of the active SGW will do not clean up sessions.

Resilient session restoration is the process of identifying a sessionthat is down or inactive, and restoring the identified session as soonas possible through the backup SGW. In resilient session restoration,the active SGW conveys enough information about each UE so that thebackup SGW can restore both control and data planes associated with theUE session. This means that the backup SGW is not only aware of theactive SGW's UEs, but processes control messages for those UEs as wellas forwarding data plane traffic for those UEs.

Resilient session restoration within the context of, illustratively, anLTE network may provide active processing times of UE within 10 ms whileminimizing the impact of network elements of a loss of a primary SGW.Very techniques also provide low synchronization overhead betweenprimary and backup SGWs, no change to idle UE processing, maintaining UEIP address for active and idle UEs and maintaining the charging session.

A session resilience phase executes whenever there is activity on asession. The goal is to recover information to establish a downlink pathto the UE. This implies that the network elements involved in thesignaling and maintenance of the session continue to hold on to thesessions so they can communicate with their peers. It is noted that aUE's session state, apart from its downlink TEID, generally staysconstant. In effect, the Idle UE session state is a relatively invariantportion of the session state of a UE. Thus, by keeping the UE in IdleMode the main restoration effort is directed toward the downlink TEID.

After an active SGW failure scenario, all traffic, whether data plane orcontrol plane, will be routed to the backup SGW. When data trafficarrives on the S5-u interface of the backup SGW, it will arrive on atunnel having a tunnel endpoint identifier (TEID) that has beenprogrammed in the data plane of the backup SGW. Since the UE state ismaintained as Idle Mode, the normal behavior of the SGW is to transmit aDownlink Data Notification message to inform the MME to page the UE, andto return the downlink TEID (DL TEID) and eNodeB for the UE. If the UEis actually in Idle Mode, then the MME will page the UE and re-establishthe downlink path. If the UE is active, then the MME does not have topage the UE, but will instead provide to the SGW the existing downlinkTEID for the eNodeB that the UE is attached to. For data arriving on theS1-u interface of the backup SGW, the uplink data path has already beenprogrammed and the data forwarding can be completed. It is noted thatthis operation is available to both and active UE and an idle UE.Downlink return traffic will trigger the Downlink Data Notification asdiscussed above.

If a control message arrives on the S5-c interface, then the backup SGWwill forward the message. If the MME does not send Modify BearerRequests, then the SGW is aware that the UE was in active state andsends a Downlink Data Notification to the MME in order to trigger theMME to send a Modify Bearer Request with the downlink TEIDs. If the UEwas idle, then the MME will automatically send the Modify BearerRequests. If a control message arrives from the MME, then it is eitherbringing the UE out of idle (the SGW doesn't have to do anything),sending an idle mode TAU (the SGW doesn't have to do anything), or it isa call flow that requires the UE not to be in idle state (the SGW throwsthe message away and sends a Downlink Data Notification, eliciting theModify Bearer Request from the MME).

In various embodiments, the TEID spaces used by the active and backupSGWs are disjoint to ensure that no collisions occur between what hasalready been programmed on the backup SGW and the UEs that it is backingup.

Generally speaking, the restoration procedure uses informationcommunicated between active and backup SGWs, such as (1) path managementRestart Counters and IP addresses of each peer known to the active SGW;and (2) all UE session state information known to the active SGW, exceptfor the downlink TEIDs to the various eNodeBs.

FIG. 3 depicts a flow diagram of a session state backup method accordingto one embodiment. The method includes portions adapted for use in aprimary SGW and portions adapted for use in a backup SGW, such as theSGWs 112 described above with respect to FIGS. 1-2.

Generally speaking, the method 300 of FIG. 3 is adapted to store at abackup SGW enough information about each UE 102 supported by an activeSGW to enable the backup SGW to take at least limited actions, such asidentifying sessions that are down or inactive, and restoring theidentified sessions as soon as possible through the backup SGW. Theactive SGW conveys enough information about each UE to enable the backupSGW to restore both the control and data planes associated with the UEsessions. In this manner, the various network elements involved in thesignaling and maintenance of the UE session will continue to view thesession as alive and communicate with their peers accordingly.

At step 310, at least one alternative or backup SGW is determined for aprimary SGW. That is, for one or more of the SGW's within a networkoperating as a primary or active SGW, at least one backup SGW isdetermined. Referring to box 315, the backup SGW may be determined withrespect to location, configuration, capacity or other factors associatedwith the primary and/or backup SGW. The determination may be made byinter-SGW negotiation, such as within the context of a discovery,configuration or optimization process among neighboring SGWs. Thedetermination may also be made by a network manager, such as the networkmanager 140 described above with respect to FIG. 1. Other entitiesand/or determination methodologies may be used.

In various embodiments, determination of an alternate or backup SGW fora primary SGW is performed automatically based on one or more of thefollowing selection criteria: DNS response times, path managementverification times, session loading and the like. In various embodimentsthe criteria is also used by the MME to select a new primary SGW for newcall setups.

At step 320, the active and backup SGWs are initialized as needed, theprimary and backup roles are allocated among the SGWs, communicationsbetween the primary and backup SGWs are established, and at least theprimary SGW begins to advertise its IP address.

Referring to box 325, the processes at step 320 includes some or all ofestablishing an inter-SGW communication channel (ISCC) with an inter-SGWcommunication protocol (ISCP) for conveying the events needs to beestablished between the active and backup SGWs, defining one or more IPsurvivability mechanisms to be used, defining the relevant events thatwill be conveyed from the primary SGW to the backup SGW, determining therange of Tunnel Endpoint Identifiers (TEIDs) that the active SGW willuse, sharing peer address and restart counter information and the like.

In various embodiments, during initialization the active SGW identifiesitself and requests identification of the backup SGW. After verifyingthat the peering is between properly configured SGWs, the active SGWdeclares that it is going to take the active role. When peering isagreed upon, the active SGW begins to advertise its IP addresses for theS1-u, S11, S5-c and S5-u interfaces. In normal operation, the active SGW“owns” the IP address on the S11, S5-c, S5-u and S1-u interfaces. Theactive SGW also shares a TEID range that it will use, so that the backupSGW can refrain from using that range.

In various embodiments, the active SGW shares with the backup SGW alocal Restart Counter for the SGW, where only one Restart Counter ismaintained for all protocols within the SGW. In some embodiments, theactive SGW shares a Peer IP address and Restart Counter pair, for eachpeer that the active SGW communicates with. In these embodiments, aspeers periodically, go, the active SGW communicates this information tothe backup SGW. This information is typically not change in a stablenetwork.

At step 330, a primary SGW transmits session state informationassociated with the mobile devices supported by the primary SGW to atleast one corresponding backup SGW. That is, as it processes UE relatedmessages, the active SGW identifies session-state relevant events forthe UE and communicates this information to the backup SGW.

Referring to box 335, the session state information may be transmittedat predetermined intervals such as after a predetermined number ofseconds or minutes. The session state information may also betransmitted after the occurrence of one or a predetermined number ofrelevant subscriber events. A relevant subscriber event comprises,illustratively, a Create Session Event, a Create Bearer Event, a DeleteSession Event, and/or a Delete Bearer Event. Generally speaking, arelevant subscriber events for purposes of a session restorationembodiment comprises any event that results in the creation ordestruction of a user session, such as given in the following examples:

Create Session Event: When a new session is created, new control TEIDsare allocated to the S5 interface towards the PGW. If this is the firstsession for the UE, then a new control TEID is allocated to the S11interface towards the MME. At the completion of the Create event, dataplane TEIDs for the default bearer are also assigned for trafficingressing or egressing the SGW on the S5-u, and ingressing the SGW onthe S1-u interface from the eNodeB.

Create Bearer Event: When a new dedicated bearer is created, new dataplane S5-u TEIDs are allocated for traffic ingressing or egressing theSGW, and ingressing the SGW on the S1-u interface.

Delete Session Event: when a session is deleted, the session needs to bedeleted from the backup SGW, and deprogrammed from the data plane.

Delete Bearer Event: When a dedicated bearer is deleted, the bearercontext needs to be deleted from the backup SGW, and deprogrammed fromthe forwarding plane.

The frequency of change is based on the frequency of setup/teardown ofPDN sessions and dedicated bearers. However, this is not as frequent asthe events that arrive at the SGW that modify the state of the sessionsand bearers. The state information primarily comprises session state ofthe UE that does not change significantly during the life of thesession.

In some embodiments, to avoid an incorrect assessment by the backup SGWthat the active SGW has indeed failed, the active SGW periodically sendskeep alive messages to the backup SGW in case there are few relevantevents to convey.

At step 340, at each backup SGW the session state informationtransmitted from one or more primary SGWs supported by the backup SGW isstored. Referring to box 345, such session state information maycomprise one or more of information sufficient to indicate a session isin an active state, information sufficient to restore a session with anactive UE, information sufficient to restore a session with an inactiveUE, information sufficient to re-create control and data planes for UEsessions or other information.

FIG. 4 depicts a flow diagram of a session state restoration methodaccording to one embodiment. Specifically, FIG. 4 depicts a method 400adapted for use in a gateway operating as an alternate or backupgateway, such as an alternate or backup SGW in an LTE network havingstored thereon session state information such as described above withrespect to FIG. 3.

At step 410, a gateway such as a SGW operating as a backup SGW isinitialized and a communications path to a primary SGW established,illustratively in accordance with method 300 as described above withrespect to FIG. 3.

At step 420, the backup gateway receives and stores UE state informationpertaining to UE supported by the active SGW until such time as afailure of the primary SGW is indicated. Referring to box 425, a primarySGW failure may be indicated via an explicit failure indication, atimeout of a neighboring node alive indicator, a peer counter timeoutand the like. Such an indication may be due to an actual failure of theprimary SGW or some other condition, such as a maintenance conditionassociated with the primary SGW or an overload condition associated withthe primary SGW.

At step 430, after a primary SGW failure, the backup gateway assumes theIP addresses and path management duties of the failed primary gateway.In some embodiments, the UEs associated with the failed SGW aremaintained in an idle state. Referring to box 435, the backup gatewaymay begin to advertise IP addresses with a preferred criteria such thatcontrol plane and data plane traffic and packets are routed to thebackup gateway.

At step 440, UE connectivity and session validity with the backup SGW isreaffirmed. That is, the backup SGW generates the various controlmessages to reestablish or reaffirm data plane and control plane UEsession data as validly supported by the backup SGW. Referring to box445, in some embodiments UE connectivity may be reaffirmed by generatinga DDN (IMSI) for use by the MME to restore S1-u dl paths, by causing UEdetach and reattach operations to thereby restore UE sessions, torestore the UE, by activating UEs previously forced into an idle stateto thereby restore data and control plane information to the UE's, or byother mechanisms.

At step 450, the backup SGW continues to support UE sessions, therebytaking over the functions of the failed primary SGW.

The specific control messages generated by the backup SGW depends uponthe session state information synchronized between the primary andbackup SGWs. Some session state information is not sufficient tomaintain UE sessions. Some session state information is only sufficientto cause a detachment/reattachment of a UE. Some session stateinformation is sufficient to retain data plane and control planesessions.

Various types of session state information and the utilization of suchinformation within the context of session restoration are discussed inmore detail with respect to simultaneously filed U.S. patent applicationSer. No. 13/423,247, filed on Mar. 18, 2012, entitled SYSTEM AND METHODFOR SESSION RESILIANCY AT GEO-REDUNDANT GATEWAYS, and Ser. No.13/423,249, filed on Mar. 18, 2012, entitled SYSTEM AND METHOD FORSESSION RESTORATION AT GEO-REDUNDANT GATEWAYS, both of which are hereinincorporated by reference in their entireties.

In various embodiments, when data plane or control plane trafficassociated with a UE session arrives at the backup SGW (i.e., backup SGWIngress Data Plane or Ingress Control Plane triggered), the backup SGWresponsively generates a DDN (IMSI) message for the MME to restore S1-uDL paths. Referring to box 445, the backup SGW generates the DDN (IMSI)message in response to a Network generated control plane or data planetraffic, UE generated data plane traffic, control messages on S11, datatraffic on S1-u or S5-u and so on.

In response to the DDN (IMSI) message, the MME operates to process idlemode UEs by (a) performing an IMSI paging function; (b) detaching the UEwhile providing a selected re-attach code; and c) performing an IMSIattach if the UE is in idle mode. The MME operates to process active orconnected mode UEs by (a) performing a detach; and (b) performing anIMSI attach. Further, the backup SGW forwards a Delete Session Requestto the PGW, which responsively cleaned up UE state anomalies via PCRFand IMS. Since the UEs are maintained in idle state (per step 430), theMME detaches and reattaches the UEs thus maintaining data plane and 12plane integrity of the sessions supported thereby.

Post Failover Handling

Generally speaking, there are two gateways or nodes participating in ageo-redundant pair. At a given time, the two gateways or nodes may beperforming independent or different functions for respective UEs and thelike. For purposes of this discussion it will be assumed that one of thenodes is a “working” node while the other node is a “protect” node. The“working” node is the one which is intended to be the one handling allthe calls in a normal state, while the “protect” is the node which isintended to backup the “working” node.

The node which is currently handling the calls flows and data flows iscalled the “active” whereas the other node which is backing up theactive is “standby”. The “active” node is the one which is currentlyhandling all the calls whereas the “standby” is the node which isbacking up the “active” node. While a revert process is occurs, theoperational state of the active will be “active-releasing” and that ofthe “standby” would be “active-acquiring”.

The node which is currently attracting control and data traffic isdenoted as the “master” whereas the other node is denoted as the“slave”.

Generally speaking, when the nodes become operational, the “working”node takes the operational state of “active” and IP address ownership as“master” whereas the “protect” node takes the operational state of“standby” and the IP address ownership as “slave”.

There are two primary actions that a service provider or networkoperator may require of the protect and standby nodes after ageo-redundant failover has occurred; namely, a non-revertive action anda revertive action.

A non-revertive action is where the provider does not want to return(failover) the protected sessions back to the initially failed “working”node once the failed working node has recovered after the failure.Specifically, after a failover occurs, the “protect” node becomes the“active” and “master” node. When the “working” node becomes operational,it takes the role of “standby” and “slave”. Both systems continue toperform in their new roles.

A revertive action is where the provider does want to return (failover)the protected sessions back to the initially failed “working” node oncethe failed working node has recovered after the failure. This action issometimes preferred when the provider expects all the sessions to berestored to the “working” system. When the geo-redundant systems are farapart, a failover can cause additional latency for traffic and may alsocost the provider for sub-optimal forwarding of packets through theirnetworks.

Revertive actions may be invoked manually or automatically. In a manualapproach, the network is monitored by the provider following a failover.Once the network is stable, the revertive action is triggered by manualintervention. In an automatic approach, the network elements themselvesdetect the stability and/or other operational criteria associated withthe network based on based on various parameters. When an appropriatelevel of network stability or other operational criteria is achieved, arevertive action may automatically be triggered.

Various embodiments enable revertive action in a manner adapted tominimize control and traffic plane losses or other disruptions.

FIG. 5 depicts a flow diagram of a revertive action method according toone embodiment. Specifically, FIG. 5 depicts a method of automaticallyreverting from a backup SGW or protect node to a previously failed SGWor working node in a manner adapted to minimize control and trafficplane loss for revertive UE sessions.

At step 510, the previously failed SGW or working node sets up a controlchannel to the backup SGW or protect node. That is, after the previouslyfailed SGW (i.e., the working node) becomes operational again, itreestablishes communications with the backup SGW (i.e., the protectnode) by setting up a control channel.

At step 520, the control protocol is used to determine the operationalstates of the working node and protect node. After a failure recovery,the “working” node (e.g., previously failed SGW) will be the “standby”and “slave” node, whereas the “protect” node (e.g., the backup SGWpresently supporting UE sessions) will be the “backup” and “slave”.

At step 530, the protect node and working node are synchronized suchthat both nodes store session state information associated with mobiledevices supported by the protect node. That is, while the protect nodecontinues to act as the active node supporting the various UE sessions,the corresponding session state information is provided to the workingnode. Referring to box 535, such session state information may compriseone or more of information sufficient to indicate a session is in anactive state, information sufficient to restore a session with an activeUE, information sufficient to restore a session with an inactive UE,information sufficient to re-create control and data planes for UEsessions or other information.

In various embodiments, the session state information synchronized withthe working node at step 530 of FIG. 5 is substantially the same as thesession state information stored at backup SGWs as previously discussedwith respect to step 340/345 of FIG. 3. However, in various otherembodiments, the session state information synchronized with the workingnode at step 530 is different than the session state information storedat backup SGWs as previously discussed with respect to step 340/345 ofFIG. 3.

For example, in various embodiments, the session state informationstored at step 340 of FIG. 3 and used to migrate UE sessions from aprimary SGW to one or more backup SGWs is the same as the session stateinformation synchronized at step 530 of FIG. 5. In various otherembodiments, the session state information stored at step 340 of FIG. 3and used to migrate UE sessions from a primary SGW to one or more backupSGWs is different than the session state information synchronized atstep 530 of FIG. 5. In various other embodiments, the session stateinformation stored at step 340 of FIG. 3 and used to migrate UE sessionsfrom a primary SGW to one or more backup SGWs is the different than thesession state information synchronized at step 530 of FIG. 5 for some orall of a plurality of backup SGWs.

At step 540, the protect node operates as an active/master node until arevertive action is triggered. That is, the “active” node will continueto act as the “master” and hence attract all traffic from the network.This will occur when using either an L2 (VRRP) or L3 (IP Addressadvertisement) mechanism. Once the protect node and working node aresynchronized with respect to session state information and, optionally,other information, a revertive action may be triggered. Referring to box545, the revertive action may be manually triggered, automaticallytriggered based on system stability, automatically triggered based onsome other criteria, such as congestion conditions proximate one or bothof the working and protect nodes, error rates, policy preferences andthe like.

At step 550, in response to the triggering of a revertive action, ahandover channel is created between the protect and working nodes. Thehandover channel facilitates handing over the protect node supported UEsessions back to the working node. In addition, the active node (i.e.,protect node or backup SGW) is transitioned to an active-releasingoperational state, while the standby node (i.e., working node or primarySGW) is transitioned to a standby-acquiring operational state.

At step 560, working node operational control of UE sessions begins tobe restored as control of all new UE session attaches is transitionedfrom the protect node to the working node. Specifically, rather thanhandling new UE attach requests locally, the protect node forwards allnew UE attach requests toward the working node via the handover channelas such requests are received or identified. The working node respondsto the new UE attach requests by interacting with the requesting UEs toperform various control functions such as establishing sessions and thelike. Following the control set up, data flows associated with the newsessions will also be forwarded to the working node such that theworking node exerts complete control over the sessions.

At steps 570-590, control of all existing UE session attaches istransitioned from the protect node to the working node. Specifically,individually or in groups, existing UE sessions are transitioned fromthe protect node to the working node using the synchronized sessionstate information discussed above with respect to step 530. Oneembodiment will now be discussed in particular with respect to steps570-590, though various modifications to this embodiment arecontemplated by the inventors.

At step 570, the working node assumes the IP addresses and pathmanagement duties of the protect node. In some embodiments, the UEsassociated with the protect node are maintained in an idle state.Referring to box 575, the working node may begin to advertise IPaddresses with a preferred criteria such that control plane and dataplane traffic and packets are routed to the working node.

At step 580, UE connectivity and session validity with the working nodeis reaffirmed. That is, the working node generates the various controlmessages to reestablish or reaffirm data plane and control plane UEsession data as validly supported by the working node. Referring to box585, in some embodiments UE connectivity may be reaffirmed by generatinga Downlink Data Notification (DDN) IMSI message for the MME to restoreS1-u DownLink (DL) paths, by causing UE detach and reattach operationsto thereby restore UE sessions, to restore the UE, by activating UEspreviously forced into an idle state to thereby restore data and controlplane information to the UE's, or by other mechanisms.

At step 590, the working node continues to support UE sessions, therebytaking over the functions of the protect node. In particular, theworking node announces its routes and declares itself as active andmaster, whereas the protect node adopts the role of standby and slave.

In various embodiments, the UEs or UE sessions that revert back to theworking node comprise only those UEs or US sessions that were previouslysupported by the working node. For example, as will be discussed in moredetail below, various embodiments contemplate that both the working andprotect nodes are associated with respective and non-conflicting IPaddress sets such that, illustratively, each may serve as a protect nodefor the other without having conflicting addresses.

In various embodiments, a revertive action may be partial due to thepresence of congestion or other criteria. For example, when a workingnode becomes operational it may not be desired to revert all UE sessionsto that node due to various network operating conditions, policy changesor other factors. In this case, only a portion of the UE sessions aremoved from the protect node to the working node. Similarly, the timewithin which the UE sessions are moved may be adapted (lengthened orshortened) based upon the various factors. Other criteria such aspolicy-based criteria, a UE subscriber service level and the like mayalso be used to adapt the revertive action. The various criteria aremanaged by either or both of the working and protect nodes, or by thenetwork management system.

The specific control messages generated by the working node depends uponthe session state information synchronized between the protect andworking node(s). Some session state information is not sufficient tomaintain UE sessions. Some session state information is only sufficientto cause a detachment/reattachment of a UE. Some session stateinformation is sufficient to retain data plane and control planesessions.

Various types of session state information and the utilization of suchinformation within the context of session restoration are discussed inmore detail with respect to simultaneously filed U.S. patent applicationSer. No. 13/423,247, filed on Mar. 18, 2012, entitled SYSTEM AND METHODFOR SESSION RESILIANCY AT GEO-REDUNDANT GATEWAYS, and Ser. No.13/423,249, filed on Mar. 18, 2012, entitled SYSTEM AND METHOD FORSESSION RESTORATION AT GEO-REDUNDANT GATEWAYS, both of which are hereinincorporated by reference in their entireties.

Thus, the various embodiments contemplate periodically transferring aportion of session state information from a primary SGW to a backup SGW(directly or via the MME) wherein the transferred session stateinformation is only sufficient to identify mobile or subscriber deviceshaving active sessions. In this manner, the backup SGW may prompt thosemobile or subscriber devices to reauthorize or reattach themselves tothe network using the IP address and other information associated withthe backup SGW. Simultaneously, “session alive” or “session active”response messages are sent by the backup SGW to inquiring managemententities on behalf of or spoofing those mobile or subscriber deviceshaving active sessions. In this manner, the session state informationassociated with those mobile or subscriber devices at the inquiringmanagement entities is preserved by the inquiring management entities.

The various embodiments described herein generally contemplates thatsession state information and/or other information associated with aprimary SGW is stored at a backup SGW for use in implementing a failovermechanism. However, in various embodiments such information may bestored at multiple backup SGWs and/or at one or more network elementsthat are not SGWs. The stored session state information and/or otherinformation associated with the primary SGW is retrieved by the backupSGW as part of the failover mechanism.

Various embodiments are modified to use one or more additionalmechanisms for accelerating the resilient session restoration process.One mechanism for accelerating the session restoration process comprisesthe use of a predefined IE on the first few Echo Requests transmittedfrom SGW to the MME to indicate that the backup SGW has taken over. TheMME responsively accelerates the recovery of downlink TEIDs of activesessions instead of waiting for data plane notification on the S5-u, orfor control messages on S11 and S5-c. One mechanism for accelerating thesession restoration process comprises periodically passing a list ofactive sessions from the active SGW to the backup SGW so that the backupSGW can proactively start populating those sessions with their downlinkTEIDs and bring them to active state faster. These and other mechanismsmay be used individually or in any combination to improve or acceleratethe session restoration process.

Synchronizing state information between the primary and backup SGWs, aswell as a frequency of such synchronization depends on various factors,such as network topology, available resources, desired speed ofrestoration and the like.

As an example, a system such as adapted for an LTE network utilizingGeneral Packet Radio System (GPRS) Tunneling Protocol or GTP maysynchronize some or all of the state information pertaining to GDPinformation, path management information and radiofrequency (RF) relatedinformation associated with various sessions or UE.

State-related GTP information may comprise, illustratively, UL/DLFTEIDs, control FTEIDs for S11 and S5-c, data FTEIDs for S1-u and S5-u,ULI and the like. State-related path management information maycomprise, illustratively, restart counters for S11, 51-u and S5 and thelike. State-related RF information may comprise, illustratively, originstate, RAT and the like (roughly 5128 per APN per APN).

Synchronization/update frequency may be predetermined, periodic natureand/or related to the various network events.

In various embodiments, primary and backup SGWs are synchronized whensessions are created and/or destroyed, such as synchronizing eightGTP/RF messages for a session create event, six GTP/RF messages for asession destroy event, and two IMCP messages for a sessioncreate/destroy event.

In various embodiments, primary and backup SGWs are synchronized whenbearers are created and/or destroyed, such as synchronizing six GTP/RFmessages for a better create event, six GTP/RF messages for a bearerdestroy event, and two IMCP messages for a bearer Create/Destroy event.

In various embodiments, primary backup SGWs are synchronized in responseto or network configuration events like MME relocations, such assynchronizing four GTP/RF messages and two IMCP messages for an MMErelocation event.

In various embodiments, dual IP addresses are used on S11 and S5 whereone addresses local in one addresses backup. The local IP addresses areused to retain existing sessions at the backup SGW, while the backup IPaddresses are used for new sessions, sessions transferred from thefailed or failing primary SGW, control traffic associated with thefailed or failing primary SGW and so on. Specifically, the IP addressallocation even to the backup SGW is split into two portions (which mayor may not be the same size), where a first portion is used for existingdata and control plane traffic at the backup SGW, and a second portionis used for data and control plane traffic associated with the failed orfailing SGW. In this manner, collisions are avoided as session supportmoves from the primary SGW to the backup SGW. That is, a backup SGWbecoming active SGW utilizes an active SGW bundle of IP addresses. Inthis manner, conference are avoided and support for sessions may betransferred between SGWs on a per-bundle basis with respect to their IPaddresses. In various embodiments, failure suppression is employed, oneother embodiments it is not employed.

Thus, two (or more) service gateways (SGWs) or nodes may be operating asa geo-redundant pair and may be denoted as a primary/backup orworking/protect gateways or nodes. The primary or working SGW or nodeoperates in a master mode, while the backup or protect SGW(s) or node(s)operate in a slave mode. In the event of a failure of the primary orworking SGW, the backup or protect SGW(s) begin operating in the mastermode. In this situation, the UEs and their sessions are “failed over” tothe slave(s). When the failed primary or working SGW/node becomesoperational again, it may be necessary to return or failover the newlysessions from the backup or protect SGW back to the primary or workingSGW/node.

In a master mode of operation, the master SGW/node advertises route datathat is preferable to the route data advertised by the slave(s) SGW suchthat any node wishing to send traffic will select the master as theroute for that traffic. To ensure that this happens, the slave SGW mayfor example advertise “poisoned” route data; namely, route data thatwould never be selected for use do to its high cost or some othernegative parameter.

FIG. 6 depicts a high-level block diagram of a general purpose computersuitable for use in performing the functions described herein withrespect to the various embodiments. In particular, the architecture andfunctionality discussed herein with respect to the general-purposecomputer is adapted for use in each of the various switching andcommunication elements or nodes discussed herein with respect to thevarious figures; namely, the UEs 102, eNodeBs 111, SGWs 112, PGW113,MMEs 114, PCRF115, and network management system 140. It will beappreciated that some of the functionality discussed herein with respectto describe general purpose computer may be implemented in variousnetwork elements or nodes, and/or a network operations center (NOC) ornetwork management system (NMS) operative to configure and manageelements within the network.

As depicted in FIG. 6, system 600 comprises a processor element 602(e.g., a CPU), a memory 604, e.g., random access memory (RAM) and/orread only memory (ROM), a packet processing module 605, and variousinput/output devices 606 (e.g., storage devices, including but notlimited to, a tape drive, a floppy drive, a hard disk drive or a compactdisk drive, a receiver, a transmitter, a speaker, a display, an outputport, and a user input device (such as a keyboard, a keypad, a mouse,and the like)).

It will be appreciated that computer 600 depicted in FIG. 6 provides ageneral architecture and functionality suitable for implementingfunctional elements described herein and/or portions of functionalelements described herein. Functions depicted and described herein maybe implemented in software and/or hardware, e.g., using a generalpurpose computer, one or more application specific integrated circuits(ASIC), and/or any other hardware equivalents.

It is contemplated that some of the steps discussed herein as softwaremethods may be implemented within hardware, for example, as circuitrythat cooperates with the processor to perform various method steps.Portions of the functions/elements described herein may be implementedas a computer program product wherein computer instructions, whenprocessed by a computer, adapt the operation of the computer such thatthe methods and/or techniques described herein are invoked or otherwiseprovided. Instructions for invoking the inventive methods may be storedin fixed or removable media, transmitted via a data stream in abroadcast or other signal bearing medium, transmitted via tangible mediaand/or stored within a memory within a computing device operatingaccording to the instructions.

While the foregoing is directed to various embodiments of the presentinvention, other and further embodiments of the invention may be devisedwithout departing from the basic scope thereof. As such, the appropriatescope of the invention is to be determined according to the claims,which follow.

What is claimed is:
 1. A method for managing a backup service gateway(SGW) associated with a primary SGW, the method comprising: in responseto a determination that the primary SGW has returned to operation,synchronizing user equipment (UE) session state information between thebackup and primary SGWs for at least those UEs previously supported bythe primary SGW; and in response to a revertive action trigger, creatinga handover channel between the backup and primary SGWs to enable atransition of UE support from the backup SGW to the primary SGW.
 2. Themethod of claim 1, wherein said determination that the primary SGW hasreturned to operation is made in response to the primary SGWestablishing a control channel to the backup SGW.
 3. The method of claim1, further comprising determining operational states of the primary andbackup SGWs using a communications protocol.
 4. The method of claim 1,wherein said session state information comprises information sufficientto indicate a UE session is in an active state.
 5. The method of claim1, wherein said session state information comprises informationsufficient to restore a session with an active UE.
 6. The method ofclaim 1, wherein said session state information comprises informationsufficient to restore a session with an inactive UE.
 7. The method ofclaim 1, wherein said session state information comprises sufficientinformation to restore control and data planes for UE sessions.
 8. Themethod of claim 1, wherein said revertive action trigger comprises amanual trigger.
 9. The method of claim 1, wherein said revertive actiontrigger comprises an automatic trigger based on at least one of a systemstability condition and a system congestion condition.
 10. The method ofclaim 1, further comprising generating one or more control messagesadapted to reaffirm UE connectivity and session validity with theprimary SGW.
 11. The method of claim 10, wherein said control messagescomprise a Downlink Data Notification (DDN) message.
 12. The method ofclaim 10, wherein said control messages are adapted to reaffirm bycausing a US to detach from the network and the reattach to the network.13. The method of claim 10, wherein said control messages are adapted toreaffirm by activating UEs from an idle state to restore thereby dataand control plane connectivity.
 14. The method of claim 1, wherein saidhandover channel is adapted to migrate to said primary SGW support forUE session newly requested of said backup SGW.
 15. The method of claim14, wherein said handover channel is adapted to migrate to said primarySGW existing UE sessions supported by said backup SGW.
 16. The method ofclaim 15, wherein: said backup SGW is associated with a set of local IPaddresses that does not conflict with IP addresses associated with saidprimary SGW; and said existing UE sessions migrated to said primary SGWcomprise only those UE sessions initially associated with IP addressesassociated with said primary SGW.
 17. The method of claim 1, whereinonly a portion of the UE sessions initially associated with the workingnode are migrated back to the working node, said portion being selectedaccording to one or more of a system stability parameter, a systemcongestion parameter, a policy-based criterion and a subscriber servicelevel.
 18. An apparatus for use in a service gateway (SGW) adapted tobackup a primary SGW, the apparatus comprising: a processor configuredfor managing a backup service gateway (SGW) associated with a primarySGW, the method comprising: in response to a determination that theprimary SGW has returned to operation, synchronizing user equipment (UE)session state information between the backup and primary SGWs for atleast those UEs previously supported by the primary SGW; and in responseto a revertive action trigger, creating a handover channel between thebackup and primary SGWs to enable a transition of UE support from thebackup SGW to the primary SGW.
 19. A non-transitory computer readablemedium including software instructions which, when executed by aprocesser, perform a method for managing a backup service gateway (SGW)associated with a primary SGW, the method comprising: in response to adetermination that the primary SGW has returned to operation,synchronizing user equipment (UE) session state information between thebackup and primary SGWs for at least those UEs previously supported bythe primary SGW; and in response to a revertive action trigger, creatinga handover channel between the backup and primary SGWs to enable atransition of UE support from the backup SGW to the primary SGW.
 20. Acomputer program product, wherein a computer is operative to processsoftware instructions which adapt the operation of the computer suchthat the computer performs a method for managing a backup servicegateway (SGW) associated with a primary SGW, the method comprising: inresponse to a determination that the primary SGW has returned tooperation, synchronizing user equipment (UE) session state informationbetween the backup and primary SGWs for at least those UEs previouslysupported by the primary SGW; and in response to a revertive actiontrigger, creating a handover channel between the backup and primary SGWsto enable a transition of UE support from the backup SGW to the primarySGW.